I am not whether we like this to have. This converts Strings to Bool without asking, changing the behaviour of conditions. This might be intentional in most cases, but if someone relies on "whatever is the output, it becomes true", this could break the logic.

If you have Inputs like this, I see two possible ways to handle this:

1. You use the always pipeline to convert variables to your needs. (already possible now)
2. We introduce a syntax where you can specify the vartype, this could be something like "myvar=[:bool:]false" or similar. Good indicators for the vartype should be found, which are very unlikely to be there by accident. This feature can be even more powerfull, because it allows also other var types, which could reduce converting lines in the automatix scripts.

While i would find this:
We introduce a syntax where you can specify the vartype, this could be something like "myvar=[:bool:]false" or similar. Good indicators for the vartype should be found, which are very unlikely to be there by accident. This feature can be even more powerfull, because it allows also other var types, which could reduce converting lines in the automatix scripts.
really good I'm afraid this would be complex to implement. But if it is easy, go ahead @sgruber-seibert

I am not whether we like this to have. This converts Strings to Bool without asking, changing the behaviour of conditions. This might be intentional in most cases, but if someone relies on "whatever is the output, it becomes true", this could break the logic.

If you have Inputs like this, I see two possible ways to handle this:

1. You use the always pipeline to convert variables to your needs. (already possible now)
2. We introduce a syntax where you can specify the vartype, this could be something like "myvar=[:bool:]false" or similar. Good indicators for the vartype should be found, which are very unlikely to be there by accident. This feature can be even more powerfull, because it allows also other var types, which could reduce converting lines in the automatix scripts.

If we introduce this syntax should we only add this to the vars-file or also to the --vars option ?
And if this is not set, should we default to strings as data type or throw an exception ?

I am not whether we like this to have. This converts Strings to Bool without asking, changing the behaviour of conditions. This might be intentional in most cases, but if someone relies on "whatever is the output, it becomes true", this could break the logic.
If you have Inputs like this, I see two possible ways to handle this:

1. You use the always pipeline to convert variables to your needs. (already possible now)
2. We introduce a syntax where you can specify the vartype, this could be something like "myvar=[:bool:]false" or similar. Good indicators for the vartype should be found, which are very unlikely to be there by accident. This feature can be even more powerfull, because it allows also other var types, which could reduce converting lines in the automatix scripts.

If we introduce this syntax should we only add this to the vars-file or also to the --vars option ? And if this is not set, should we default to strings as data type or throw an exception ?

I would say: string is the default and all variables are processed this way, whereever they come from. It could be a "hard" match, where the options are hardcoded. Alternatively it could be flexible and you just write the casting funktion there which is executed. This would be very powerful, but has also some risks.

While i would find this: We introduce a syntax where you can specify the vartype, this could be something like "myvar=[:bool:]false" or similar. Good indicators for the vartype should be found, which are very unlikely to be there by accident. This feature can be even more powerfull, because it allows also other var types, which could reduce converting lines in the automatix scripts. really good I'm afraid this would be complex to implement. But if it is easy, go ahead @sgruber-seibert

I don't think it's too complex. But there might be some little obstractles when we go in there in detail, especially to ensure, that only and exact that is converted, what you intend.